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ABSTRACT 



In an exemplary embodiment, the server receives the client's 
Distinguishing Name (DN), and then searches its directory 
for identification information and access control rights for 
this specific context. The server can act as a stand-alone 
server or in conjunction with other directory services on the 
network. A client must have a verifiable identity in order for 
secure communications to continue. A client's identity can 
be said to be fully verifiable if the server has access to the 
directory service that maintains that client's DN. The client 
receives the server's DN, and the client can then determine 
whether or not to accept a response to a request for infor- 
mation (i.e., trust the response). The client determines the 
identity of the server using some directory service (the client 
can act stand-alone or as a client of other directory servers). 
A server is fully verifiable if the client can identify the 
directory service that maintains the server's DN. In both 
cases, determining identity is predicated on being able to 
identify a directory service. Since servers and clients are 
issued identities (DN's) from some directory service before 
they participate in secure communications, they are able to 
at least identify their "home" directory service. Their 
"home" directory service communicates with other directory 
services, each "serving" their lists of electronic identities to 
each other using secure directory services. In this manner, a 
client or server can verify the peer identity of a secure 
communicator by relying on the trusted "home" directory 
service. Public Key certificates, certificate revocation lists, 
pending certificate requests, Certification Authority policy, 
and other information is stored in the directory server. 
Access to the directory server is through secure communi- 
cations; this maintains the integrity and privacy of the 
information. 

25 Claims, 8 Drawing Sheets 
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Fig.3 
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o3 Lyiiem iniiiaies communications 
by opening up a network connection 
to the server 


Client 


—p ► 

v 3b Server responds to connection, 
and demands identification 
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v 3c Client sends identity for this session, 
in the form of a digital certificate. 
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Fig. 4 



Certificate 



::= SIGNED SEQUENCE { 
version [OJVersion DEFAULT 1988, 

serialNumber SerialNumber, 
signature Algorithm i dent if i er 

issuer Name 



subject 

subjectPublicKeylnfo 



nidir 
Name, 
SubjectPublicKeylnfo} 



Version ::= 


INTEGER { 1988(0)) 


SerialNumber ::= 


INTEGER 


Validity ::= 


SEQUENCE { 


notBefore 


UTCTime, 


notAfter 


UTCTime) 


SubjectPublicKeylnfo 


::= SEQUENCE { 


algorithm 


Algorithmidentifier 


subjectKey 


BIT STRING) 


Algorithmidentifier ::= 


SEQUENCE} 


algorithm 


OBJECT IDENTIFIER 


parameters 


ANY DEFINED BY algorithm 
OPTIONAL) 
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Client identity (digital certificate), 
Communications Context (context 
descriptor), and Server Identity 
(digital certificate) 



no 
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Fig.6A 



The directory service checks that the digital certificate 
issuer's public key is available to the directory service 
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86 




No 



The directory service verifies that the digital signature 
on the certificate matches the internally stored public key 
of the certificate issuer 



Si 



90 




NO 



The directory service verifies that the certificate is still currently 
valid by checking the internally stored certificiate status, or optionally 
against an internally stored Certify Revocation List 



XL 



94 




No 



The directory cross references the client certificate, the server 
certificate, and the communications context in order to retrieve an 
internally stored Access Control Rule to apply to the client connection 



Verification component returns 
an Access Rule for the Client 
to Server Session to block 76 
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Fig. 7 



Verification_Descriptor 


::= SEQUENCE! 


Clientidentity 


Certificate, 


ContextDescriptor 


Context, 


Server identity 


Certificate } 



Fig. 8 



Context ::= SEQUENCE ( 

version [OjVersion DEFAULT 1 996, 

time UTCTime, 
protocol OBJECT IDENTIFIER 

parameters ANY DEFINED BY protocol 
OPTIONAL} 

Version ::= INTEGER { 1996(0) } 



Fig. 9 



IssuerName = Verification_Descriptor->Clientidentity-> Issuer 
IssuerPublicKey = ::= SEQUENCE { 

algorithm Algorithmidentifier 

Key BIT STRING} 

Algorithmidentifier ::= SEQUENCE { 

algorithm OBJECT IDENTIFIER 

parameters ANY DEFINED BY algorithm 
OPTIONAL) 



Fig. 10 



Clientidentity ::= SIGNED SEQUENCE { 



) 

IssuerPublicKey = :: 
algorithm 
Key 

Algorithmidentifier :: 
algorithm 
parameters 



SEQUENCE { 

Algorithmidentifier 

BIT STRING} 
SEQUENCE { 

OBJECT IDENTIFIER 

ANY DEFINED BY algorithm 

OPTIONAL} 
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Fig. 11 



Clientidentity ::= Certificate 
CertificateRevocationList ::= ATTRIBUTE 

WITH ATTRIBUTE-SYNTAX CertificateList 
AuthorityRevocationList ::= ATTRIBUTE 

WITH ATTRIBUTE-SYNTAX CertificateList 
CertificateList ::= SIGNED SEQUENCE! 

signature Algorithm identifier, 

issuer Name, 

lastUpdate UTCTime, 

revokedCertificates 

SIGNED SEQUENCE OF SEQUENCE{ 
signature Algorithmidentifier, 
issuer Name, CertificateSerialNumber subject, 
revocationDate UTCTime} 
OPTIONAL) 



Fig. 12 



ACL = Retrieve_ACL from Internal Database (Clientidentity, 
ContextDescriptor, Serveridentity) 



Fig. 13 



ACL_Rule ::= SEQUENCE { 

towhat OBJECT IDENTIFIER, 

towhat_parameters ANY DEFINED BY towhat 

OPTIONAL 
bywhat OBJECT IDENTIFIER, 

bywhat_parameters ANY DEFINED BY bywhat 

OPTIONAL 
access INTEGER) 

Version ::= INTEGER { 1996(0) } 
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METHOD OF AND APPARATUS FOR the present invention, cryptographic keys may be resident in 

PROVIDING SECURE DISTRIBUTED & user's own directory services, while permitting users to 

DIRECTORY SERVICES AND PUBLIC KEY securely communicate with each other as a result of using 

INFRASTRUCTURE the distributed directory services described herein. The 

S present invention utilizes secure distributed directory ser- 

FIELD OF THE INVENTION v j ccs t 0 maintain a public key infrastructure, and does not 

The invention generally relates to the field of digital data °P erate in the conventional global, top-down hierarchy 

processing communications systems in which a user at a wn & a "meta-certifier", who must certify all users in order 

workstation requests information or services from a server t0 provide the desired level of security, 

computer. More particularly, the invention relates to a 10 In accordance with an exemplary embodiment, users may 

method of and apparatus for providing a public key infra- receive digital certificates from various other users and still 

structure via secure directory services within a computer securely communicate with each other with sufficient secu- 

system and/or a computer network. rity such that electronic business transactions may be cul- 
minated. The present invention incorporates the use of 

BACKGROUND AND SUMMARY OF THE is po i icy statements which efficiently permit trust levels to be 

i in vcn liuiN applied to a user's service request based upon an analysis by 

With the widespread and ever mushrooming use of the recipient of the message sender's identity via the dis- 

network-based communications, a business world where tributed directory services system. Thus, the fact that a 

electronic-based business transactions are the rule rather particular message sender is identified in a given distributed 

than the exception has been a longstanding vision shared by 20 directory service using designated policy statements, per- 

many. A major stumbling block to widespread electronic mits the message recipient to determine the degree of trust 

business transactions is the need to effectively deploy a to be given to a message sender. 

secure communications system providing privacy, message The exemplary embodiment implements the concept that 

integrity, non-repudiation and authenticity. by being able to uniquely identify a client in a specific 

Cryptographic systems have been widely used to ensure 25 communications context, a server can assign the cheat with 

the privacy and authenticity of messages communicated specific access rights for that context. The access rights 

over a wide variety of different networks. Many conven- granted to a client depend on the client's identity in that 

tional cryptosystems are not satisfactory for widespread context. 

business world deployment due to well recognized problems 3Q Given that access rights are based on identity, the feature 

relating to, for example, key distribution. of being able to uniquely identify a client becomes signifi- 

Public key cryptographic systems have been advanta- cant. The server requires a secure and infallible method of 

geously utilized to solve existing cryptographic system identifying the client. The infallible method is based on 

problems including key distribution problems. Such public using secure directory services of the nature described in the 

key cryptographic systems use a public key/private key pair 35 present exemplary embodiment. By securely receiving iden- 

and decouple the encrypting and decrypting processes such tity verification services from a directory service, the server 

that the encrypting process key is separate and distinct from can then determine the access rights to grant to a client. This 

the decrypting process key. In such systems, given the allows a server to deliver client-sensitive information, with- 

knowledge of the encryption key and an encryption key that out prior knowledge of the client. 

is large enough, it is not viable to compute the decryption 40 i n accordance with an exemplary embodiment of the 

key and thus the encryption key for users may be distributed present invention, a client initiates a secure connection with 

or published. Anyone desiring to communicate with a user a server providing directory services. The server, taking 

at a particular destination, encrypts a message under the advantage of the authentication feature in the secure com- 

destination user's public key. Only the destination user who munications methodology described herein, uniquely iden- 

retains the secret decrypting key of the public key/private 45 ufies the client and thus obtains the client's distinguished 

key pair is able to decipher the transmitted messages. nam e (DN). The server uses the client's DN to determine 

In public key cryptographic systems, it is known that a what access rights to grant the client, either by looking up 

trusted authority may create a digital message which con- the client's DN in its own directory or by recursively acting 

tains a claimant's public key and the name of the claimant. as a client to another directory server that contains definitive 

A representative of the trusted authority digitally signs the 50 information about that particular DN. The directory server 

digital message with the authority's own digital signature. then returns the information to the client that is specific to 

Such a digital message, referred to as a digital certificate is that client and is able to do so by taking advantage of the 

transmitted along with the use of the claimant's own digital authentication feature provided by the secure communica- 

signature. See U.S. Pat. No. 4,405,829 issued to Rivest et aL, tions methodology used herein. 

which discloses exemplary methodology for a practical 55 \ n accordance with another aspect of the present 

public key cryptographic system implementation. Also see invention, a client initiates a secure communication with a 

U.S. Pat. No. 5,214,702, which describes a public key digital server. The methodology described herein is also applicable 

signature cryptographic system having enhanced digital t0 mc instance where the client and server are on the same 

signature certification. machines so that the network described herein may be 

Existing public key cryptography methodologies envision eo internal to the computer in this special case. The server is 

that electronic business transactions employ a global stan- able to uniquely identify the client based on the authentica- 

dard for tying the public key use to a high level global tion feature of the secure communications server as a 

authority, using what is referred to as the X.500 standard. directory service to verify the identity of the client's DN and 

Not all users, however, participate in this global standard, for access control permissions to grant to the client. This 

thereby limiting the standard's practical utility. 65 communication with the directory service must be over a 

The present methodology does not rely on a global secure communications channel because the information 

standard. In accordance with an exemplary embodiment of passed on to the client/server communication depends on the 
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result and verification and access rights returned by the 
directory service. The directory service responds to the 
server with verification information and access control 
information, particular to that client and the server is able to 
determine what information should be sent to the client. The 
server then returns either none, some or all the information 
requested by the client. 

In an illustrative embodiment, the identities of the parties 
involved determine the access rights for a directory service's 
communications context. All requests for information made 
by the client, receive customized directory service 
responses. The peer identities are determined through the 
use of secure communications. 

In an exemplary embodiment, the server receives the 
client's Distinguishing Name (DN), and then searches its 
directory for identification information and access control 
rights for this specific context. The server can act as a 
stand-alone server or in conjunction with other directory 
services on the network. A client must have a verifiable 
identity in order for secure communications to continue. A 
client's identity can be said to be fully verifiable if the server 
has access to the directory service that maintains that client's 
DN. 

The client receives the server's DN, and the client can 
then determine whether or not to accept a response to a 
request for information (i.e., trust the response). The client 
determines the identity of the server using some directory 
service (the client can act stand-alone or as a client of other 
directory servers). A server is fully verifiable if the client can 
identify the directory service that maintains the server's DN. 

In both cases, determining identity is predicated on being 
able to identify a directory service. Since servers and clients 
are issued identities (DN's) from some directory service 
before they participate in secure communications, they are 
able to at least identify their "home" directory service. Their 
"home" directory service communicates with other directory 
services, each "serving" their lists of electronic identities to 
each other using secure directory services. In this manner, a 
client or server can verify the peer identity of a secure 
communicator by relying on the trusted "home" directory 
service. 

The present exemplary implementation of the invention 
can be used to implement a Public Key Infrastructure in the 
following manner. Public Key certificates, certificate revo- 
cation lists, pending certificate requests, Certification 
Authority policy, and other information is stored in the 
directory server. Access to the directory server is through 
secure communications; this maintains the integrity and 
privacy of the information. Administrators acting in the 
capacity of the Certification Authority are granted full access 
to the repository, by issuing them the "Administrator's DN", 
and can add new certificates, modify certificate revocation 
lists, etc. Others would have less access, to the limit that 
unknown parties may only be allowed to submit certificate 
requests or download public certificates (and revocation 
lists). Additionally, certificates can be used as vectors in 
directory searches; the client attempting the directory search 
has its access limited by its client DN, and the client's DN 
may not contain a name at all, but rather a hash of the client's 
policy. In this manner, certificates can be issued that contain 
minimal information; in fact, they only need to contain a 
unique identifier that can be used as a vector in the vector 
space (this would be the entire namespace that is visible to 
that particular client). 

BRIEF DESCRIPTION OF THE DRAWINGS 

These as well as other features of this invention will be 
better appreciated by reading the following description of 
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the preferred embodiment of the present invention, taken 
into conjunction with the accompanying drawings of which: 
FIG. 1 is a block diagram of an exemplary communica- 
tions system within which the present invention may be 
5 utilized; 

FIG. 2 is a data flow diagram showing illustrative data 
communicated between a directory client and a server; 

FIG. 3 is a data flow diagram exemplifying how a client 
may be identified in a secure communications protocol; 
10 FIG. 4 is an example of a digital certificate which may be 
used in conjunction with FIG. 3; 

FIG. 5 is a flowchart of the general sequence of operations 
performed in accordance with an exemplary embodiment; 

FIGS. 6 A and 6B are a flowchart delineating an exem- 
1 5 plary sequence of operations involved in the identification 
verification process; 

FIG. 7 is an exemplary verification descriptor object/data 
structure; 

FIG. 8 is an exemplary context descriptor object/data 
20 structure; 

FIG. 9 is an exemplary data structure/object utilized in 
conjunction with FIG. 6A, block 80, verification analysis; 
FIG. 10 is an exemplary object/data structure used in 
25 performing verification analysis of FIG. 6 A, block 86; 

FIG. 11 is an exemplary object used in performing the 
verification analysis of FIG. 6A, block 90; 

FIG. 12 is an exemplary object/data structure used for 
retrieving an access control list rule; 
30 FIG. 13 is an access list control rule object/data structure. 

DETAILED DESCRIPTION OF AN 
EXEMPLARY EMBODIMENT OF THE 
INVENTION 

35 FIG. 1 shows in block diagram form, an exemplary 
computing system within which the present invention may 
be utilized as part of an electronic commerce/ 
communications network. It should be recognized that, 
while the present methodology may be utilized in such a 

4Q communications network environment, the invention may 
likewise be used in conjunction with a wide range of data 
processing systems, including one or more laptop 
computers, stand-alone, PC-type computers, 
minicomputers, and any other computer system environment 

45 where data security is a significant concern and practically 
implementable. 

Before describing an exemplary communications system, 
which may be used in conjunction with the present 
invention, terminology utilized herein is first described. A 

50 "client process" or program runs on a computer attached to 
a network. The client process is distinguished by the fact that 
it makes requests for information or services. The client 
process may be referred to herein as a client. 

A "server process" also runs on a computer attached to a 

55 network. The server process is distinguished by the fact that 
it fulfills requests for information or services. The server 
process may be referred to herein as a server. It should be 
recognized that a client and a server may actually run on the 
same computer and that a server may be a client to another 

60 server. 

As used herein, "secure communications" typically refers 
to any data transport mechanism, which preferably provides, 
but is not limited to, privacy, message integrity, non- 
repudiation, and authenticity. 
65 A "Distinguished Name" (DN) uniquely identifies an 
entity participating in a digital conversation preferably 
enabled via secure communications. 
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A "communications context" is an instance where a client been applied to a program requesting information or 

is requesting information from some server, and the request services, a client may also be hardware or circuitry embod- 

for information can be distinguished by one or more of the ied in, for example, a Smart Card Reader requesting infor- 

following: client DN, server DN, information requested, mauon or services. 

information available, and access controls on that informa- s LAN 13 includes a client/server 12, which may, for 

ti oa example, be a SUN Microsystems SPARC, which is a 

Turning back to FIG. 1, this figure shows an exemplary RISC-based workstation. LAN 13 also includes a client 

communications network including multiple client comput- workstation 10 which may be a Mac II manufactured by 

, . j , . i • */ *• Apple Corporation, and a client/server 14, which may be a 

ing devices, and combination client/server computing ser- , . , , in ^- *\ A , 

... . • i i 1 a !i u m DEC workstation. Workstations 10, 12 and 14 are exemplary 

vices interconnected via local networks, and through an 10 » * l« £ 

, . , mi i , . 1 /T a kt \ l • i-T/- 1 workstations which may be coupled to a LAN each of which 

Internet. The local area networks (LANs) shown m FIG. 1, . •-!.«. . «■ 

i.e., LAN 1 and LAN 13 are depicted for illustration may be mnnmg different opwatmg systems, 

purposes only. These networks are intended to be represen- Although the LANs 1 and 13 are coupled together via the 

tative of any of the many network designs, such as Ethernet, In,ernet 22 > . me ' hod a T nd apparatus may be advanta- 

token ring, or other type of networks having attached clients is g eouslv utuized ^"*™« connections. Thus for 

and servers which are likewise intended to be subsumed by e * am P le > ■» i^office network may distribute digital cer- 

the FIG. 1 architecture. By way of example only, LAN 1 tificates and secure information in accordance with the 

may be an Ethernet 802.3 10 base T network. A variety of P resenl invention. It should be understood that the present 

protocols run on LAN 1, including TCP/IP and NETBIOS. invention may be employed with any subset of the structure 

Although numerous protocols may be running on LAN 1, 20 shown in FIG. 1. 

TCP/IP is preferably utilized, which is the protocol that runs FIG ' 2 » a data flow diagram showing illustrative data 

on the Internet communicated between directory client 40 and server 42, in 

As shown in FIG. 1, LAN 1 includes a PC-type computer accordance with an exemplary embodiment of the present 

2 operating solely as a client, which may, for example, be a "J™*™- ^ f ent 40 ma 7 b f' fo^xample, any 

Windows 95-based workstation. LAN 1 additionally « of thc enumerated clients previously described above m 

includes a workstation 3 which may, for example, be an IBM «"J«fioii ™th FIG. 1. Similarly, server 42 may be, for 

RS 6000, operating as both a client and a server. The IBM « am P le > ^ of ^ se T VB,s ldentlfied ab ° V6 >? FIG - 1; ^ 

no cnnn *_ • n *u a iv ** * „ Pr +/ directory server 44, the secure communications protocol 

RS 6000 typically runs the AIX operating system. Client/ , ao j 

u i- • • *u ♦ f *u- component 46, the directory access component 4o, and the 

server 3 may be running as a client in the context oi the ■ , * A 4 - 

_ fV _^,_„, A ^- UaA ?„ 0 ; n nn Ai nr oc o „™r ;*o 30 internal directory database 50 are resident in server com- 

methodology descnbed herein and/or as a server having its JU . ' ~ ^ , . A 

-™ y ain ^^^.r^ ™™ puting device 42. As set forth above, directory client 40 

own X.50U directory space. * • r *■ e aA * An 

, .. Aft requests information or services from a server 42. Client 40 

LAN 1 also includes a minicomputer server 4, which may . idtatmtd ^ a direct clierit and is merefore mlging 

be any commercially available minicomputer. Minicom- ^ information. The directory itself may be distrib- 
uter server 4 may, for example, be dedicated to providing 3s ^ and virtuaU a nere in tne nG> x network . 
digital certificates or directory services Minicomputer ^ ^ M information ardi individual users 
server 4 may be attached to another network (not shown). As and c ate entities such as? for examplej may be OTn . 
suggested by inclusion of minicomputer server 4, servers are ^ ^ a ^ ge For exampk) mc directory 
not limited to workstation type devices. may indude cliem data inchlding a Distinguished Name or 
LAN 1 may, for example, also include a graphics-based 4Q anothcr utuqiJC c ii ent identifier. In addition to the client 
SGI client/server 6, which may be one of the workstations identifier, a directory may store public key information for 
manufactured by Silicon Graphics Corporation. Client/ identifying the public key of the party to which it is desired 
server 6 may perform computer graphics and/or CAD opera- t0 securely communicate. Directory Server 44 within server 
tions. Workstation client 8 may, for example, be an IBM 42 operates in accordance with a preestablished directory 
PC-based work station and is representative of the numerous 45 prot0 col to serve directory information to directory clients, 
additional available workstations which may, if desired, be If the directory server 42, by accessing its associated internal 
coupled to LAN 1 . data base 50, can adequately respond to the client's directory 
The secure communications with directory services of the related query, server 42 appropriately responds. If not, the 
present invention occur not only on the exemplary LAN 1, question may be responded to by server 44 by returning a 
but also on LAN 13. LAN 13 also runs protocols including 50 referral to directory client 40 to identify the location of a 
TCP/IP for Internet communication. server which can respond. Alternatively, directory server 44 
LANs 1 and 13 may, for example, communicate via the may be chained to other directory servers and may attempt 
Internet 22, via routers 16 and 18. Routers 16 and 18 are to find the answer to the inquiry, rather than sending a 
conventional routing computers for Internet referral to directory client 40. In this context, the directory 
communications, having sufficient memory capacity to per- 55 server 44 operates as a client to another directory server, 
form necessary routing functions and keep track of the The secure communications protocol component 46 
devices with which they are associated on the Internet. A ensures that the directory client 40 communicates with 
router provides a quick connection between two devices on directory server 44 using a secure communications protocol, 
the Internet. A router 16,18 may serve more than one LAN. The secure communications protocol preferably provides 
The routers 16 and 18 may, for example, be routers com- 60 privacy, authentication, non-repudiation, and integrity to the 
mercially available from Cisco Corporation. communications between client 40 and server 42. In con- 
Various other clients such as Smart Card Reader 20 and ventional systems, no response is provided when a client is 
laptop client 24 may be attached to, and communicate with, not entitled to access a server. In accordance with the present 
any of the other depicted devices through the Internet via invention, a response may be obtained from a directory 
phone lines 23,25. Smart Card Reader 20 may, for example, 65 server which indicates whether the client 40 has enough 
be a Visa card reader. With respect to Smart Card Reader 20, privilege to get the requested information as will be 
although the concept of a "client" described thus far has described further below. 
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The directory access component 48 of server 42 permits client's communication session. Alternatively, it may return 

communication with the server's internal database 50. The an access denied in the case of an untrusted client. Once the 

server 42 determines via the direct access component 48, client's identity is confirmed, an access control list is 

what type of access the client 40 is entitled to have. accessed to retrieve the access rules that apply to the 

In operation, in accordance with step 2a, server 42 5 communications session. This information is returned to the 

receives the client identity from the directory client 40 using directory service protocol 46 via the directory access com- 

the underlying secure communications protocol. Because p U ter 48. 

the communications protocol provides authenticity wi(h t , o ^ ^ commumcations session j, 

assurance, toe client ^^^^^AsoO^^tt cstablished ^ te clien , and ^ retricved acc6SS mtm l 

receives a known identity which can later be verified. mi r j * *u • *• t *u- 

, . . it, i- . 1 10 rules are applied to the communications session. In this 

FIGS. 3 and 4 show an example 01 how a client may be r , - 4 , , , , c t . « 

• *• *i * fashion, a client may be precluded from re tneving directory 

identified using a secure communications protocol. As . . ' . . 4 / * - •« j u 

t-c -j * 1 1* * cn • ♦ ,™ m formation that it is not entitled to retrieve, as specified by 

exemplified in FIG. 3, client 60 initiates communication t , „ _ T _ _ . ' . 

... £1k „ „ „„ „ . f L 0 access control rules. While FIG. 2 shows the communication 

with server 62 by opening up a network connection to me JA 

server. The precise matter of initiation will depend on the between a directory client 40 and a directory server 42, the 

nature of the network. Server 62 responds to the connection 35 methodology is intended to be applied to a client and server, 

and demands that client 60 identify itself. Client 60 then For example, the server may act to retrieve access control 

sends its identity for this communication session in the form rules for clients going to its web site, 

of a digital certificate to server 62. By way of example only, FIG. 5 shows in flowchart form a general sequence of 

the secure communications protocol utilized may be the operations performed in accordance with an exemplary 

commercially available SSL protocol, which in accordance 20 embodiment of the present invention. As indicated in FIG. 5, 

with the present invention is advantageously applied to initially the client sends its Distinguished Name (DN) which 

directory services to provide a secure directory services umque ly identifies the client (70). Thereafter, the server 

s y stem - receives the distinguished name DN (72). 

FIG. 4 is an example of a digital .certificate 64 which may an cliem 
be used to identify the client as described in conjunction 25 & t & . £ . . ♦ 1 1 * 
with FIG. 3 above The digital certificate may be, but is not f ™ Ihe appropriate ACL access ^control rules to 
required to be, structured as recommended in the X.509 W 1 * M mdicated b V the "^cursive parenthetical m block 
standard. The certificate may be custom designed to include 74 > server mav acoess other Rectory servers throughout 
numerous different and/or additional fields as desired. The the Intemet in order t0 determine the appropnate access 
certificate may be written, for example, in ASN.l syntax. 30 rules to apply. In addition to access control rules, degree of 
The digital certificate 64 includes a "certificate" field which trust related information which may be associated with the 
is a digitally signed sequence, that includes a hash of the data client also may be accessed from different servers on the 
identified below, which is then encrypted with the signing Internet. The server, by making requests to other directory 
party's private key. Within the information that is digitally servers on the Internet, itself becomes the client in its effort 
signed is a version number, a serial number which uniquely 35 to provide the access control and trust rules to apply to the 
identifies the certificate, and the signature of the signing client. Thus, in the context of a web site, if a client sends its 
party in accordance with an identified algorithm such as distinguished name DN (or an alternative identifier) to a web 
RSA. Additionally included within the signed certificate site > tne wcb site nccds to identify the client either at an 
information is an identification of the certificate issuer, internal data base at its associated server or at other web 
identifying the name of the party that signed the digital 40 si tes - The web site can then seek identifying information 
certificate. The certificate includes a validity field which from other directory server web sites until a trust relation- 
specifies how long the certificate is valid. The subject field ship with the requesting client is determined. With such 
specifies the name of the party who holds the certificate, and information retrieved from other directory servers, the 
the public key information field specifies the public key of degree of trust which may be associated with the requesting 
the subject. The fields referred to above are expanded in 45 client ma y be determined. 

FIG. 4 to show their constituent construction in more detail. If the client is verified in block 74 processing, ACL 

FIG. 4 thus shows an exemplary data structure of a digital information is returned to the directory server as indicated in 

certificate which may be used in conjunction with the block 76 and is applied to the data connection. The access 

present invention. control rules and trust related information are applied to the 

Turning to back to FIG. 2, in accordance with step 2b, the 50 data connection to ensure that actions take place during the 

server 42 checks if the client identity is recognized by the data connection in accordance with the access control rules 

internal directory data base. Thus, if directory client 40 and/or the trust information, to thereby ensure that authori- 

transmits client identity information in the form of a digital zation levels are not exceeded. 

certificate, such as that shown in FIG. 4, server 42 checks the In accordance with this methodology, for example, a 
digital certificate to confirm recognition from its internal 55 digital certificate possessed by a party which has been issued 
data base 50. The server 42 initially checks the digital by Visa may be transmitted to a web site and an electronic 
certificate to confirm that the signature of the issuer matches transaction may take place, whereby goods are purchased, 
the signer's signature. Thus, if the internal directory data The transaction may be completed in accordance with the 
base 50 has no information regarding the certificate's signer, client's credit rating which may be checked, for example, 
the client will not be identifiable. Under such circumstances, 60 through Visa's directory server. The Visa directory server 
the server 42 may act as a client to retrieve the required may determine the nature of the credit rating to transmit 
signer's public key information from another server to depending upon the particular context, e.g., the party at the 
complete the identification. Details of this process are web site requesting the information and the individual client, 
described in further detail in conjunction with FIG. 6 and During this process, the web site would likewise be trans- 
subsequent figures described below. 65 mitting to the Visa directory server its digital certificate so 
Once the identity of the client is verified, the internal that the Visa directory server can determine whether the web 
directory returns an access control rule to apply to the site is, for example, a business which has recently gone 
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bankrupt, or another bank which should be associated with 
a great deal of trust. In this fashion, the present invention 
enables the transaction parameters to be fully developed in 
the particular communications or business transaction con- 
text. 

In accordance with FIG. 5 at block 78, having obtained 
the appropriate access control list rules and/or trust 
information, such information is applied to the data connec- 
tion. The data requested is transmitted back to the client, as 
shown in FIG. 5, although the access control rule or trust 
level information would not be communicated. The process 
may be repeated in connection with different subsequent 
communication sessions. 

FIGS. 6 A and 6B are a flowchart delineating the sequence 
of operations involved in an exemplary identification veri- 
fication analysis. The input data to the directory server 
verification analysis component is the client identity which 
may include the digital certificate as, for example, shown in 
FIG. 4, communications context information which is a 
context descriptor that describes the nature and/or type of 
communication and a server identity which is the server's 
digital certificate. The directory server verification analysis 
flowchart shown in FIGS. 6 A and 6B is implemented by 
software embodied within the directory server 42 shown in 
FIG. 2. 

FIG. 7 is an exemplary verification descriptor object and 
FIG. 8 is an exemplary context descriptor data structure 
utilized in the verification analysis shown in FIG. 6. Turning 
first to the verification descriptor, the data structure/object 
shown in FIG. 7 includes a digital certificate identifying the 
client and a digital certificate identifying the server as well 
as a context descriptor. In the case of a null context 
descriptor, the context defaults to that of the directory server 
protocol. Thus, if there is no context descriptor, the context 
is presumed to be a communication session between a client 
communicating with a directory server. Alternatively, if a 
web client is communicating with a web server and the web 
server is performing a verification analysis, then the context 
descriptor is set to indicate a web server communicating 
with a web client. In the case of a null server identity, the 
server defaults to the directory server itself. If communica- 
tion takes place between a web client and a web server, the 
web server inputs its web identity via its digital certificate. 

As shown in FIG. 8, the illustrative context descriptor 
includes a version number field and a time field which 
indicates the coordinated universal time. The "protocol" 
field varies depending upon the particular communications 
context. For example, if a web server is communicating with 
a web client, the protocol may be the web protocol "http". 
If an E-mail client is communicating with an E-mail server, 
then the protocol may be the "SMTP" protocol. 
Additionally, any parameters defined by the protocol may be 
listed in the context descriptor. 

Turning back to FIG. 6A, block 80, the directory server 
checks that the digital certificate issuer's public key is 
available to the directory server. For example, if Visa issued 
a digital certificate to a requesting party, a check is made at, 
for example, a web site to determine whether the web site 
can identify Visa and has access to Visa's public key. If the 
certificate issuer is known, then the digital signature of the 
certificate issuer may be verified. 

Based upon the block 80 analysis, a determination is made 
as to whether the certificate issuer is known (82). If the 
certificate issuer is not known, then the directory acts as a 
directory client to attempt to find a known certificate issuer. 

After the directory server acts as a directory client to find 
a known certificate issuer, a check is made at FIG. 6B, block 
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84, to determine whether a known certificate issuer has been 
found. If so, the routine branches back to block 80, and the 
routine continues. If no known certificate issuer is found, 
then access is denied. 

5 An exemplary data structure or object utilized in conjunc- 
tion with the block 80 analysis is shown in FIG. 9. As shown 
in FIG. 9, the certificate issuer's name is identified by using 
the verification descriptor's client identity and the issuer's 
identity information. As shown in FIG. 9, the verification 

10 process utilizes the issuer's public key and verification 
algorithm identifier information. If the data structure shown 
in FIG. 9 has a null or blank "issuer public key" field, 
resolving the unknown certificate issuer may involve either 
storing information from another directory in a local cache, 

15 acting as a directory service client to another directory 
service, or permitting an unknown signature by deferring 
resolution until the access control rules are searched. By 
permitting an unknown signature to be utilized, the system 
may accept the unknown signature, while relying on the 

20 access control rules to determine whether this is appropriate. 
For example, certain web sites may not care who the 
certificate issuer is and, in fact, wish to promote the web site 
to be accessed. Under these circumstances, the accessible 
control list rules may include specific restrictions identifying 

25 the context where an unknown certificate issuer is involved. 
Turning back to FIG. 6 A, if the certificate issuer's public 
key is available, the directory services verifies at block 86 
the digital signature, such that the digital signature on the 
issuer's certificate matches the internally stored public key 

30 of the certificate issuer. 

FIG. 10 shows an example of an object or data structure 
required to perform the verification operations of FIG. 6 A, 
block 86. As shown in FIG. 10, the client identity is used 

35 which consists of the signed sequence embodied in a digital 
certificate previously discussed in conjunction with FIG. 4. 
The issuer's public key is also used which includes the 
information shown, including an algorithm identifier. Thus, 
the client identity, which is a signed sequence defined by a 

40 digital certificate, permits the signature to be verified with 
the issuer's public key. 

A check is next made at FIG. 6A, block 88 to determine 
whether the signature is good. If the signature is bad, then as 
shown in FIG. 6B, access is denied or, as previously 

45 described, a decision may be made to defer resolving this 
issue until the access control rules are checked. 

If the check in block 88 indicates that the signature is 
good, then, as indicated in block 90, the directory service 
verifies that the certificate is still currently valid by checking 

50 an internally stored certificate status or optionally, a check is 
made of an internally stored certificate revocation list. 

FIG. 11 shows exemplary objects or data structures which 
may be used in performing the verification indicated at FIG. 
6A, block 90. As shown in FIG. 11, the client identity 

55 information includes the digital certificate previously dis- 
cussed. The certificate revocation list is a list of certificates 
which have been previously revoked and may be presented 
as attributes with an attribute -syntax certificate list. The list 
would be in the form of a signed sequence of certificates as 

60 shown in FIG. 11. The signed sequence includes the certifi- 
cate serial numbers and the revocation date. The certificate 
revocation list would be prepared by the controlling direc- 
tory service entity. If the certificate serial number identifying 
a client is stored in a certificate revocation list kept at a 

65 directory service and the certificate is revoked, the certificate 
revocation list may only be modified by those who are 
properly authorized. The revocation list may be prepared 
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and revised by an authority connecting to the directory 
service having more expansive rights than the typical client. 
Such authority would include the authority to write into such 
data structures as the certificate revocation list. Such a 
connection would typically take place only with the direc- 
tory service administrator's digital certificate. The directory 
service may not need to maintain a full certificate revocation 
list since it may be constructed from the raw data stored in 
the directory service. Thus, information may be stored in the 
directory service indicating that a particular certificate is not 
valid. Raw data stored in the directory service permits per 
certificate lookups for validity purposes. The certificate 
revocation list may be retrieved from a local cache, from 
another directory service or deferred until the ACL rule 
check. 

Turning back to FIG. 6A, based on the processing in block 
90, a check is made to determine if there is a valid certificate 
(92). If there is not a valid certificate, as determined by the 
check in block 92, then connection is denied or deferred as 
previously described. 

If there is a valid certificate, then, in accordance with 
block 94 processing, the directory cross-references the client 
certificate, the server certificate and the communications 
context to retrieve an internally stored access control rule to 
apply to the client connection. 

FIG. 12 discloses an exemplary object or data structure 
which may be used for the block 94, FIG, 6 processing, for 
retrieving an access control rule, an example of which is 
shown in FIG. 13. The set of access control rules are defined 
in the directory service database. Various directory servers 
may be linked so that access control rules stored in other 
directory servers may be utilized and may be required in 
order to fully determine the access control rules that apply. 
The directory servers may be linked based upon prearranged 
contractual trust relationships. For example, a trust relation- 
ship with a Visa card may require that Visa trust a given 
merchant and its cardholder, and that the merchant trust the 
Visa cardholder. The ACL rule is accessed by the server 
itself by use of the context and the client certificate and the 
server's certificate. An ACL rule is retrieved from the 
server's internal database, based on the client identity, the 
context descriptor (which may, for example, indicate 
whether E-mail or a web site related transaction is involved), 
and the server identity. 

As shown in FIG. 13, the ACL rule is a digital sequence 
including a "to what" field, which, for example, may indi- 
cate that the rule applies to a web page. An ACL rule may 
also include parameters associated with the "to what" field 
which may, for example, include a web page address or a 
credit card number, the nature of the card and/or the card- 
holder's name. A "by what" field may also be included, 
which typically includes the client's certificate, which may 
be identified by a client ID. "By what" parameters are 
included which may be, for example, a digital certificate. An 
"access" field may also be included and is comprised of an 
integer defining the allowable directory access modes. By 
way of an example access integers 0-4 may respectively 
indicate search, compare, read, write or none. The access 
control rule may also include a version number. 

If the certificate issuer's signature or the certificate revo- 
cation list checking operations were deferred until FIG. 6 A, 
block 94 processing, then these events are passed on as part 
of the context field shown in FIG. 12. Additionally, the 
certificate revocation list can be part of an access control rule 
fist in the deferred case. Additionally, it is noted that trust 
levels can be defined in an access control list rule. The 
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access control rules may be retrieved from a local cache 
memory, or from another directory service. Limits may be 
placed on any particular limitation as to when access control 
rules must be kept local or when they may be retrieved from 
another directory service. 

Turning back to FIG. 6A, the access control rule is applied 
to the data connection so that the client only receives the 
correct and intended data. The verification component thus 
returns an access rule to be applied for the client to the 
server. 

While the invention has been described in connection 
with what is presently considered to be the most practical 
and preferred embodiment, it is to be understood that the 
invention is not to be limited to the disclosed embodiment, 
but on the contrary, is intended to cover various modifica- 
tions and equivalent arrangements included within the spirit 
and scope of the appended claims. 

What is claimed is: 

1. A method for providing secure communications 
between a client at a first workstation and a computer, 
comprising the steps of: 

receiving at said computer, a request from said client for 
at least one of information and services, said request 
including at least one digital certificate identifying said 
client; 

checking at said computer to determine if the issuer of 

said digital certificate is recognized; 
verifying that said digital certificate is valid; 
retrieving, if the digital certificate is valid, an access 

control rule to apply to the communication session with 

said client during which at least one of information and 

services is provided to said client; 
applying said access control rule to the communications 

session; and 

wherein said computer includes a directory and wherein 
said step of applying said access control rules includes 
the step of permitting the client to access said directory 
only in accordance with said access control rules. 

2. A method for providing secure communications 
between a client at a first workstation and a computer, 
comprising the steps of: 

receiving at said computer a request from said client for 
at least one of information and services, said request 
uniquely identifying said client; 

checking at said computer to determine if the client is 
recognized by said computer; 

retrieving, if said client is recognized, an access control 
rule to apply to the communication session with said 
client during which at least one of information and 
services is provided to said client; and 

applying said access control rule to the communications 
session with said clients, 

wherein said computer includes a directory and wherein 
said step of applying said access control rules includes 
the step of permitting the client to access said directory 
only in accordance with said access control rules. 

3. A method for providing secure communications 
between a client at a first workstation and a computer, 
comprising the steps of: 

receiving, at said computer, a request from said client of 
at least one of information and services, said request 
including at least one digital certificate identifying said 
client; 

checking at said computer to determine if the digital 
signature in the digital certificate is valid; 
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retrieving an access control rule to apply to the commu- 
nication session with said client during which at least 
one of information and services is provided to said 
client; and 

applying said access control rule to the communications 
session with the client, 

wherein said computer includes a directory and wherein 
said step of applying said access control rules includes 
the step of permitting the client to access said directory 
only in accordance with said access control rules. 

4. A method for providing secure communications 
between a client at a first workstation coupled to a network 
including a plurality of computers, comprising the steps of: 

receiving at a first computer a request from said client for 
at least one of information and services, said request 
uniquely identifying said client; 

checking at said first computer to determine if the client 
is recognized; 

checking at a second computer coupled to said network, 
to determine if the client is recognized; 

retrieving from said second computer, if the client is 
recognized, an access control rule to apply to the 
communications session with said client during which 
at least one of information and services is provided to 
said client; and 

applying said access control rule to the communications 
session with said client, 

wherein said computer includes a directory and wherein 
said step of applying said access control rules includes 
the step of permitting the client to access said directory 
only in accordance with said access control rules. 

5. A method for providing secure directory services com- 
munications between a client at a first workstation and a 
computer comprising the steps of: 

transmitting from a client's workstation a request for 
directory services to said computer for at least one of 
information and services, said request including digital 
information for uniquely establishing that said client 
has a known identity which can subsequently be unam- 
biguously verified; 

checking to determine if the client is recognized by said 
computer; 

retrieving an access control rule to apply to the commu- 
nication session with said client during which directory 
services is provided to said client; and 

applying said access control rule to the communications 
session with said client. 

6. A method according to claim 5, further including the 
step of accessing information related to the degree of trust 
which may be associated with said client. 

7. A method for providing secure communications 
between a client at a first workstation coupled to a network 
including a plurality of computers, each of said plurality of 
computers including a directory server and an associated 
data base, comprising the steps of: 

transmitting from said first workstation to a first computer 
of said plurality of computers a request from said user 
for at least one of information and services, said request 
uniquely identifying said client; 

checking by the first computer's directory server, the 
associated data base at said first computer to determine 
if the client is recognized by said first computer; 

checking by the second computer's directory server, the 
associated data base at said second computer coupled to 
said network, to determine if the client is recognized; 
and 
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retrieving from said second computer, if the client is 
recognized, an access control rule to apply to the 
communication session with said client during which at 
least one of information and services is provided to said 
S client. 

8. A method according to claim 7, further including the 
step of accessing trust related information from the internal 
data base of said second computer. 

9. A method according to claim 8, further including the 
10 step of applying the trust related information and the access 

control rule to the client's request to ensure that authoriza- 
tion levels are not exceeded. 

10. A method according to claim 7, wherein said request 
is a request for an electronic business transaction transmitted 

15 to a web site. 

11. A method according to claim 7, wherein the request is 
a request for a business transaction and wherein the server 
which recognizes the client develops transaction parameters 
in the context of the parties involved. 

20 12. A method according to claim 7, wherein said trans- 
mitting step includes the step of uniquely identifying the 
client via a digital certificate. 

13. A method according to claim 7, wherein said trans- 
mitting includes the step of transmitting data uniquely 

^ identifying the client including the client's public key. 

14. A method according to claim 7, wherein said step of 
checking by said first computer's directory server includes 
the step of checking to determine if the public key of an 
identified certifying party is stored in said associated internal 

30 data base. 

15. A method according to claim 7, further including the 
step of applying said access control rules to permit the client 
to access said directory only in accordance with said access 
control rules. 

35 16. A method according to claim 7, wherein said client 
requests access to a web site via said request and further 
including the step of applying said access control rules to 
permit the client to perform operations at said web site only 
in accordance with said access control rules. 

40 17. A method for providing secure directory services 
communications between a client at a first workstation and 
a computer having a directory server comprising the steps 
of: 

transmitting from a client's workstation a request for 
45 directory services to said computer said request from 
said client including at least one of information and 
services, said request including a digital certificate for 
uniquely establishing that said client has a known 
identity which can subsequently be unambiguously 
50 verified; 

verifying by said directory server the authorization for the 
server to comply with the request based upon at least 
one digital certificate and information related to the 
request context; and 
55 retrieving an access control rule to apply to the commu- 
nication session with said client during which directory 
services is provided to said client. 

18. A method according to claim 17, further including the 
step of applying said access control rule to the communi- 

60 cations session with said client. 

19. A method according to claim 17, wherein said request 
includes the client's public key. 

20. A method according to claim 17, wherein said com- 
puter includes an internal data base and wherein said step of 

65 verifying includes the step of checking to determine if the 
public key of an identified certifying party is stored in said 
internal data base. 
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21. A method according to claim 18, wherein said com- 
puter includes a directory and wherein said step of applying 
said access control rules includes the step of permitting the 
client to access said directory only in accordance with said 
access control rules. 

22. A method according to claim 18, wherein said client 
requests access to a web site via said request and wherein 
said step of applying said access control rules includes the 
step of permitting the client to perform operations at said 
web site only in accordance with said access control rules. 

23. A method according to claim 17, further including the 
step of accessing information related to the degree of trust 
which may be associated with said client. 

24. Apparatus for providing secure directory services 
while responding to a request for information or services by 
a client at a first workstation comprising: 

a secure communications input module for receiving from 
said client's workstation a request for directory services 
including at least one of information and services, said 
request including a digital certificate for uniquely 
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establishing that said client has a known identity which 
can subsequently be unambiguously verified; 
a directory server module for responding to said request; 
and 

s a database for storing information indicative of the public 
key of the issuer of the client's digital certificate and for 
storing access control rules to apply to requests; 
said directory server module being operable to verify the 
authorization for the server to comply with the request 
1° based upon at least one digital certificate and informa- 
tion related to the request context and for retrieving an 
access control rule to apply to the communication 
session with said client during which directory services 
are provided to said client. 
1 5 25. Apparatus according to claim 24, wherein said direc- 
tory server module to operable to apply said access control 
rule is applied to the communications session with said 
client. 
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